drm/vc4: hvs: Populate YUV to RGB matrices for GEN_6D #7043
Conversation
drivers/gpu/drm/vc4/vc4_hvs.c
Outdated
| * put it before. | ||
| */ | ||
| struct vc6_d0_csc_coeff_entry { | ||
| u32 csc[3][4]; |
There was a problem hiding this comment.
Are we likely to get any value from the third and fourth elements in the array, given that they're all fixed and 2 of the 6 aren't used?
There was a problem hiding this comment.
True, it's only the actual matrix that changes, and that is contained within the first 2 u32's of each row. Leaving the clamping and flag for offsets before multiply as fixed would work.
|
Thanks, this seems to mostly work (although I can't tell if the colour matrices are actually the right ones, just that they are different now). However, with full-range, BT2020 and BT601 look identical, which I'm pretty sure is wrong. |
I'd taken the basic numbers from https://gist.github.com/yohhoy/dafa5a47dade85d8b40625261af3776a and then done the relevant shifts to make up our table. For BT2020: So assuming I have the right source coefficients, they don't appear that radically different. |
|
Comparing to a Pi 4, they do look noticeably different there. And also with EGL_EXT_image_dma_buf_import's colorspace and range options. I think it's your BT2020 which is wrong (it shows greens noticeably darker than BT601 on pi4 and EGL) |
|
Converting backwards from the GEN4/5 register values I get which is close enough to to put down to rounding due to 2p8 fixed point representation. More poking required. |
|
Wood from the trees - it's 2020 limited range that is still the same as 601 limited range. I could have sworn I'd found a doc with that one in, but obviously not. |
All the matrix entries for the YUV to RGB conversion matrices were being filled with the same coefficients. Compute the values for the BT601, BT709, and BT2020 matrices in both full and limited range, and program those into the hardware. Signed-off-by: Dave Stevenson <[email protected]>
6by9
force-pushed
the
rpi-6.12.y-drm2
branch
from
5db5de6 to
94a5f92
Compare
|
Branch updated with new coefficients for BT2020 limited range. Having captured frames via writeback using |
|
Thanks! Confirmed that with my test all 6 matrices now look different. |
kernel: dtoverlays: adjust inbound windows for MIP1 on Pi 5 with 32-bit PCIe DMA See: raspberrypi/linux#7049 kernel: drm/vc4: hvs: Populate YUV to RGB matrices for GEN_6D See: raspberrypi/linux#7043 kernel: DRM command line parser fix See: raspberrypi/linux#7051 kernel: Overlays: rpi-power-hat i2c_arm enable See: raspberrypi/linux#7055 kernel: configs: Add CONFIG_W1_SLAVE_DS2430=m See: raspberrypi/linux#7056 kernel: media: i2c: imx219: Scale the pixel rate for analog binning See: raspberrypi/linux#7045
kernel: dtoverlays: adjust inbound windows for MIP1 on Pi 5 with 32-bit PCIe DMA See: raspberrypi/linux#7049 kernel: drm/vc4: hvs: Populate YUV to RGB matrices for GEN_6D See: raspberrypi/linux#7043 kernel: DRM command line parser fix See: raspberrypi/linux#7051 kernel: Overlays: rpi-power-hat i2c_arm enable See: raspberrypi/linux#7055 kernel: configs: Add CONFIG_W1_SLAVE_DS2430=m See: raspberrypi/linux#7056 kernel: media: i2c: imx219: Scale the pixel rate for analog binning See: raspberrypi/linux#7045
All the matrix entries for the YUV to RGB conversion matrices were being filled with the same coefficients.
Compute the values for the BT601, BT709, and BT2020 matrices in both full and limited range, and program those into the hardware.
@cillian64 Hopefully this resolves your issue in getting no change between the settings.
I believe the matrices are correct, but don't believe we have any tests to confirm (we probably ought to, and it shouldn't be too difficult if extending John's drmu 10bittest which already captures the output of the writeback connector).